When a network node like a mobile network base station, e.g. an “evolved Node B” (eNB), is delivered from a vendor to an operator, the operator needs methods to integrate the network node into the operator's network in an efficient but still secure way. Efficient means here that the operator does not need to do any configuration of the network node before connecting it initially to the network, but can do all the configuration remotely after the initial connect, in a “plug and play” fashion. This is very important for many operators, in particular when the number of network nodes to be connected to the network is high, as it is often the case when building up or extending a mobile network. Secure means here that the operator can be sure that it is not possible that during the initial network connect, some attacker can gain control over the network node and possibly manipulate it, for example in a way that results in the network node connecting to the operator's network with the attacker as a “man-in-the-middle” between the network node and the operator's network. Note that the interconnection of the network node to the operator network may not be physically protected and/or owned by the operator itself—the network node may even connect to the operator network using the Internet, which is a particular insecure network.
On the other hand, the vendor, who typically delivers network nodes of the same type to different operators, desires an efficient manufacturing process that allows manufacturing all network nodes in a uniform way, without the need to configure the nodes specifically for the operator they are delivered to. So the network nodes cannot be configured with, for example, an operator “root of trust”, like a (root) certificate containing a public key of the operator. Therefore, during initial network connect the network nodes cannot verify whether they are really connecting to the correct operator network or to an attacker's network. In the latter case, they would be open to usage and manipulation by the attacker.
According to the prior art, a number of approaches are used or have been discussed (e.g. in 3GPP SA3):
Approach 1) The network nodes are physically connected and are configured remotely without any authentication. This is efficient but provides no security. It may be applicable if the network nodes are connected to the operator via protected, private links (e.g. base stations are connected to a private access network owned by the operator).
Approach 2) The network nodes are manufactured with each an individual id, a private/public key pair and a certificate for the public key signed by a vendor CA (certificate authority), possibly via a chain of intermediate certificates. The vendor CA certificate is known to the operator, e.g. securely transmitted before. When selling a network node, the vendor transmits the id of the network node in a secure way to the operator. This way the operator can authenticate the network node when it is connected to the operator network. This approach has been specified in two variants by 3GPP for the initial enrolment of eNBs (see 3GPP TS 33.310 and TS 33.401):
2a) In addition to the configuration described above, the network node is preconfigured with a public key of the operator, i.e. with an operator certificate. This allows that the network node can authenticate the operator network when it is connected to the operator network initially. Thus, mutual authentication is possible. However, the procedure is not efficient, as the network node must be pre-configured for use in the specific operator network by the vendor or by the operator.
2b) The network node has no operator specific pre-configuration. When it is initially connected to the operator network, the operator network can authenticate the network node (but not vice versa). The operator network provisions an operator certificate remotely during the initial connection. After this step, the network node can authenticate the network using the operator certificate. This is a “plug and play” solution, but leaves open an attack window: At the initial connect, an attacker could trick the network node to connect to a node controlled by the attacker. The attacker could then either just use the network node for his own purposes (“hijacking” the network node), or he may succeed to manipulate the network node in a way that it subsequently connects to the intended operator network, with the attacker still being able to control the network node. This would be a severe security breach for the operator network. 3GPP has considered this vulnerability to be acceptable and has therefore specified this solution as an allowed enrolment variant.
Approach 3) The vendor configures the root certificates of all possible operators into the network nodes. However this approach would not protect one operator against being attacked by another operator. Moreover, it is a problem to have to store a large amount of operator certificates securely within the network nodes.
Approach 4) The vendor signs certificates for all the operator root certificates. However, this approach would not protect one operator against being attacked by another operator. Moreover, it is undesirable to have such a dependency between the operator's and the vendor's PKIs.
Approach 5) The vendor operates a vendor specific “enrolment server”. The network nodes are programmed to connect to the vendor enrolment server after initial network connect. With the credentials as described in variant 2 and a vendor root certificate configured in the network node mutual authentication between network node and vendor enrolment server is possible, so a security association can be established and the vendor can provide the operator root certificate to the network node. The big disadvantage of this approach is that the vendor gets involved in the operation of the operator's network this way, and must provide the enrolment server in a way that it is always available and reachable from all the networks the network nodes may be connected to.